1. Field of the Invention
This invention relates to the internal structure of a database for an open systems interconnection (hereinafter referred to as the OSI) management system. Specifically, this invention relates to the structure of a management information base (MIB) and its maintenance.
2. Description of the Related Art
The basic concept of network management was not yet established at the initial stage of an OSI reference model for a computer networking. There was no mechanism for controlling a total network for the OSI reference model. The increase in the number of nodes connected to a network has inevitably expanded the scope of communication networking, necessitating a network manager to grasp the status of all managed objects on the network accurately and in real time. The OSI management system is designed out of this necessity to optimize resource management of a network. In response to multiple requests and needs, the OSI divides network management functions into the following five;
1. Fault management PA0 2. Accounting management PA0 3. Configuration and name management PA0 4. Performance management PA0 5. Security management PA0 (1) To flexibly add or delete an instance to update the containment relationships of the instances in the database of the network manager with utilizing the object-oriented concept, PA0 (2) To maintain the MIB with ease, PA0 (3) To not waste resources each time an instance stored in the MIB is added or deleted.
The fault management function keeps a record of error occurrences, receives error detection notifications and takes corrective measures, and diagnoses symptoms.
The accounting management function accounts or computes costs according to the usage of the network resources.
This function collects data, and identifies and administers the network resources for uninterrupted network services, which include;
setting system parameters, PA1 activating and deactivating network resources, PA1 collecting data that affects network status, PA1 updating network configuration. PA1 collecting statistical data for analyses and plans, PA1 keeping the system use records, PA1 measuring and monitoring the amount of data transmission so as to prevent network overload, and PA1 diagnosing network operation to check for incorrect data.
This function is vital for evaluating the operating status of network resources and communication efficiency, and includes the following:
The security management is responsible for preservation of network resources through authorization, access management, encipherment, and maintenance of security records.
The standardization of the OSI network management is still in the making. For instance, how managed information is typically stored in an MIB is not yet agreed upon, thus leaving the definition to each system.
FIG. 27 gives a general idea of a conventional OSI management system, which is made up of two major networks: i.g., a management network 100 and a managed object network 200. The management network 100 is responsible for the resources contained in the managed object network 200. The resources in the managed object network are referred to as the managed objects. They are further grouped into two systems. System 210 has a local area network (LAN) 211 and a workstation 212. System 220 has a private branch exchanger (PBX) 221, a personal computer 222, a time division multiplexer (TDM) 223, and a workstation 224. All these objects are systematized to build a network responsive to user needs. The managed object network 200 provides a system for implementing user jobs.
The management network 100 is configured by multiple agents 102a-102c, a manager 101, a management information base (MIB) 110, and a network 103. The agents 102a, 102b, and 102c directly monitor and manage the managed objects in the managed object network 200. The agents send and receive information necessary for the network management to and from the managed objects. The information received from the managed objects is then forwarded to the manager 101, which oversees the agents. The OSI management is carried out in accordance with the management protocol, and the information transmitted through the manager, agents, and the managed objects are stored in the MIB 110 as the management information. The method of storing information in the MIB is unique to individual systems, as the OSI standard has not been established yet.
The structure of management information is laid out in FIGS. 28(a), 28(b) and 29(c). The most important factor that comes into play in structuring the network management information is its extensibility. The managed information can never be a fixed because managed objects are constantly altered, added, deleted, or updated in real time. One typical method that has been developed is an object oriented type of design. The main feature of the object oriented type of design is that it has introduced the concept of a class and an instance. The class defines characteristics common in certain objects and the instance stands for concrete items having those characteristics defined by the class. FIGS. 28(a), 28(b) and 28(c) give some ideas about the class and the instance. The items in ovals represent the class whereas those in rectangles indicate instances. In of FIG. 28(a), the class computer has the instances such as a personal computer, a workstation, and a small business computer. In FIG. 28(b), for the class personal computer, there are such instances as an 8-bit machine, a 16-bit machine, and a 32-bit machine. In FIG. 28(c), the class animal contains such instances as a dog, a cat, and a horse. Classes for the OSI management are referred to as the managed object class and the instances are to the managed object instance, or simply the instance.
FIG. 29 illustrates an example of managed object classes in a form of an inheritance tree. Each oval indicates a managed object class and all classes are the subclasses of the top class. Characteristics of the superclasses are inherited by the subclass; the subclass definition may add to these characteristics but may not remove any characteristics of the superclass. The characteristics here include attributes, action, notification, and behavior. In FIG. 29, for example, a subclass network inherits all the characteristics of a superclass system. A subsystem workstation also inherits all the characteristics of the system.
FIGS. 30(a) and 30(b) illustrate an example of a containment tree of managed object instances. Managed object instances are uniquely named on the basis of the containment tree, which represents the containment relationship of the managed object instances. FIG. 30(a) shows how a managed object instance is expressed. The managed object instance is expressed by an object identifier of the managed object class and a distinguished name given to a managed object instance. Expressions shown in FIG. 30(a) are applied to a containment tree in FIG. 30(b). The vertical linkage or a hierarchy of the containment tree indicates a parent-child relationship: the horizontal linkage brother-brother relationship. The managed object network 200 in FIG. 27 finds its expression in this containment tree, in that the system 210 and the system 220 come as the subinstances to the root, and below the system 210 come the LAN 211 and the workstation 212.
All managed object instances have a name attribute type. The name attribute type and a value of the type of the attribute are grouped into a set and forms a relative distinguished name or RDN. The RDNs of the workstation 212 and the workstation 224 are identical, namely, (WSID="W1"). On the other hand, RDNs listed in the hierarchical order is called a distinguished name or DN. For instance, the DN for workstation 212 is {systemID="XYZ"}{WSID="W1"} as opposed to {systemID="OPQ"}{WSID="W1"} for workstation 224. In this way, the workstation 212 and workstation 224 may be uniquely identified with their DNs despite that their RDNs are the same.
FIG. 31 illustrates the logical structure and FIG. 32 shows the physical structure of an inheritance tree designated in the Japan unexamined patent publication 3-231352. FIG. 32 shows the physical structure under which the inheritance tree is actually stored in the MIB. The managed object classes in FIG. 32 are represented as nodes, each of which is provided with a left and a right pointers. The left pointer points a parent-child relationship and the right pointer is used to indicate brother-brother relationship. These two pointers on left and right remarkably expedite the search of an inheritance tree.
FIG. 33 shows the MIB data structure reported at the 42th Information Processing Society of Japan (1-169 to 1-170) in spring 1991. The attribute information of an instance is accessed through an instance information table 400. The instance information table not only retains addresses for instances immediately on its upper, lower, left and right sides, but also stores the forward address with which to carry out forward pointer search. The upper, lower, left, and right addresses are used to search the containment tree. The forward address is used to identify lower instance groups contained in a certain instance. Employing these two methods of binary tree search and forward pointer search permits an efficient search of instances. The instance information table is referenced from an agent information table 410. The agent information table and instance information table are stored by each agent. Addresses in the class information table 500 are sorted into upper and lower addresses to facilitate class information search. An attribute information table 520 stores class attributes, which can be referenced with the attribute list information in the class information table.
Problems to be solved by this Invention
The sheer enormity of the amount of data to be stored in an MIB renders the system configuration a critical factor in network management. The easy-to-operate system configuration that enables high-speed access to instances and dynamic updating of management information is imperative. For a conventional OSI management system, because the relationships and the structure of the managed objects are incorporated statically at the installation of system application or at the compilation of the application programs, the containment relationship among the managed objects or the structure of the management information base have to be built into by the application, thereby hindering a flexible system configuration.
When characteristics of a superclass had to be changed, for instance, the subclass also has to be redefined based on the new definition of the superclass, and the related programs have to be recompiled and relinked. The conventional MIBs shown in FIGS. 31, 32, and 33 are designed to solve such problems and to realize a high-speed access to instances and dynamic updating required each time the network configuration was modified. These systems still have some aspects that need improvement in light of comprehensive and flexible system configuration for both managed object classes and managed object instances.
As has been previously noted, the standardization of the network management is still in the making and the method of storing management information in an MIB varies from one system to another.
Accordingly, it is a primary object of the present invention to propose a new MIB file configuration and to provide an OSI management system based on the file configuration. Moreover, this invention aims at providing effective means for configuration and name management of the management mechanisms previously mentioned. These objectives are:
Another objective of the present invention is to provide a system that allows more efficient maintenance and operation of a network management. The managed objects, which used to be statically incorporated in the MIB at its creation based on the OSI reference model, are to be dynamically updated.